this is great to know the files but it won't get us the caller. I tried from a frida script to get the stack trace:

Stack trace:
0x74addead90 libjavacore.so!0x28d90
0x74addead90 libjavacore.so!0x28d90
0x700eda04 boot-core-libart.oat!0x12a04
0x700eda04 boot-core-libart.oat!0x12a04

maybe we can create another example for the Java/Kotlin methods

"java.io.FileOutputStream", "$init"
"java.io.FileWriter", "$init"
"java.io.BufferedWriter", "$init"
"java.io.PrintWriter", "$init"
"java.io.OutputStreamWriter", "$init"

Hooking open will miss the files created using the MediaStore API because it seems to typically leverage pre-existing file descriptors or obtain them through complex interactions with content providers, which manage the actual file operations on behalf of the app.

If we'd hook open and write, when a MediaStore API operation occurs we'd only see write and not to open.

Do you think hooking contentResolver.insert(MediaStore.Downloads.EXTERNAL_CONTENT_URI, contentValues) will be enough to cover MediaStore? Or should we also hook OutputStream? Or maybe get a file path by FD from write?

Maybe we can merge this one with https://github.com/OWASP/owasp-mastg/pull/2594/files#diff-10572627ebb61180bb70a16dc8ec124986d53d4d012be5515179570cd4c99732

We could replace this test with another one that is solely focused on the files themselves.

• Benefits: quick way to get file changes and search sensitive data on them
• Limitations: we'll only see files for the current testing session and we won't know what part of the code is responsible

Steps:

1. Setup the initial time

start_time=$(date +%s)

2. Exercise the app

3. Diff and pull all new/changed files

adb shell "find /sdcard/ -type f -newermt @${start_time}" > new_files.txt

mkdir -p new_files
while read -r line; do
  adb pull "$line" ./new_files/
done < new_files.txt

Evaluation: inspect the files and if they contain sensitive data this test fails.

Good idea. I will add it as another test

I see what you were saying in our last call about this info being valid for all tests

For now you can keep it here but later, we can put it out of here.

As you may know we have new MASTG components for tests, techniques and tools but we're going to define a new one for "theory" or "knowledge". Currently we have all knowledge in this kind of chapters but it will be split into individual files such as MASTG-KNOW-0001.md (which will contain metadata as well, in this case sth. like title: External Storage). This way we can reuse it and reference to it from tests and other components and keep them as concise as possible.

https://github.com/OWASP/owasp-mastg/blob/master/Document/0x05d-Testing-Data-Storage.md#external-storage

Again, nothing to do for now, just keep it here until we decide otherwise.

This example seems to be about Scoped Storage, maybe we can adapt the title and text to it.

I created a new example that you can use for the non-scoped storage case: output-demo-4.zip